Information stored by applications may be viewed as two types, namely, application data and cached data. Application data is data that an application, or its users, depend on for normal operation. Examples of application data may include bank account information stored by a bank application, or a document saved by a word processing application. Application data may be regarded as requiring “100% storage reliability”, because application data that is written to a storage device must always be retrievable.
Unlike application data, cached data is data that the application does not depend on for normal operation, but that is stored in order to possibly benefit from for purposes of accelerating application operation. Specifically, a cache is a temporary storage area where frequently used data can be stored for rapid access. This data is referred to as cached data. Once the data is stored in the cache, future use by an application can be made by accessing the cached copy rather than re-fetching or recomputing the original data, so that the average access time is shorter. An example of cached data may be pages stored by a Web browser after the pages were viewed, just in case the user wants to view the pages again. In this example, if the user wants to view the pages again, but the cached copies of the pages which were written to the cache are no longer found, the browser will maintain its normal mode of operation, by bringing that information from the web site itself
FIG. 1 is a block diagram illustrating a basic prior art file system. For exemplary purposes, FIG. 1 shows that there are multiple applications, illustrated as application blocks 101, 102, and 103, that wish to manipulate files (store, write, read, delete, or other function calls). The applications 101, 102, 103, call on a common, operating system level file system application programming interface (API) 104 that is capable of implementing the manipulation commands. The file system API 104 is implemented by a file system driver 105, which uses smaller blocks of data as the basic building blocks of the files. These blocks of data, are manipulated by a block storage handler and device driver 106. It is noted that the file system API 104, file system driver 105, and the block storage handler and device driver 106 are each provided by an operating system. The actual data is stored on a physical block storage device 107, which may be a hard disk, flash memory, solid state disk, or a different storage device.
As is known by those having ordinary skill in the art, for each memory block, the block storage handler and device driver maintain data that describes the memory block. This information about the block may contain the address of the memory block, size, or other characteristics of the memory block. As is also known, a file system typically has two types of blocks, namely, “used,” which are blocks that currently contain data which is to be kept, and “free,” which are blocks that may be used by the file system to store data in the future. A memory block typically has metadata associated with it, where the metadata that may include any type of information related to the block that is useful for the operating system.
FIG. 2 is a schematic diagram illustrating a prior art block storage device 110. As shown by FIG. 2, the block storage device 110 has blocks that are classified as either “free” or “used.”
Unfortunately, file systems today treat “reliable data” (application data) in the same way that the “non-reliable data” (cached data) is treated. Specifically, both application data and cached data are stored into “free” memory blocks, after which the block is categorized as “used.” This brings about a reality where applications are careful about how much cached data is saved, so that enough room is left on a storage device for the application data. The result is lower performance for the overall system than may theoretically be achieved.
Thus, a heretofore unaddressed need exists in the industry to address the aforementioned deficiencies and inadequacies.